System and method for enabling arbitrary components to transfer data between each other

ABSTRACT

Methods and systems for enabling arbitrary components to transfer data without having a priori knowledge of each other. The data transfer system includes a set of arbitrary components associated with one or more universal data transfer interfaces. The one or more universal data transfer interfaces comprise a data source interface and a data sink interface. The universal interfaces can be provided to and performed by each other to enable the components to transfer data between each other despite utilizing different communication protocols or understanding different data types. Further, the components may directly request and directly receive data from other components or may initiate transmitting data directly to other components. Moreover, a component may initiate a data transfer session between one or more other components to enable the components to transfer data between each other.

FIELD OF THE INVENTION

[0001] This invention relates generally to communication systems andmethods and, more particularly, to a system and method for enablingarbitrary components to transfer data between each other using one ormore universal data transfer interfaces employing mobile code.

BACKGROUND OF THE INVENTION

[0002] In data communication environments, such as a distributednetwork, many different vendors provide a number of products forspecific services. Heretofore, a predetermined set of domain specificprotocols has been required to be specified to enable arbitrarycomponents in the environment to communicate with each other, assumingthe components were transmitting or receiving data, hereinafter referredto as (“transferring data”). For example, a device manufactured by onevendor would have difficulty communicating with a device manufactured byanother vendor without using the predetermined set of protocolsmentioned above. The problem of different vendors requiring differentpredetermined protocols has been partially dealt with by adoptingexisting protocol standards. However, there are different standardsorganizations and thus different protocol standards.

[0003] When arbitrary components such as computer applications orprograms, data, memory, file directories, individual files, printerdevices, cellular telephones, facsimile machines, copier machines,scanner devices, desk-top computers, lap-top computers, personal digitalassistant (“PDA”) systems, or any other device, for example, attempt tocommunicate without having a priori knowledge of each other, particulardomain-specific protocols, such as the file system domain (e.g., NFS andCIFS) or the printer domain (e.g., IPP and LPR), must be known a prioriby both parties to successfully communicate. An arbitrary component,such as a PDA attempting to communicate with a file system, or a printerdevice attempting to do the same, must be explicitly programmed tounderstand one or more of the standardized protocols mentioned above. Anexample includes a computer device or application having to beprogrammed to understand a printer device by installing adomain-specific printer driver. If the device or application isprogrammed to understand how to communicate and use a printer device,generically, the driver will only enable the device or application toaccess a particular type of printer device and not the universe of allprinter devices. Thus, when new and unknown components enter theequation, the application must be reprogrammed to understand the newstandardized protocols used to communicate with the new components.Referring to the above computer and printer device example, if a newtype of printer were introduced, the computer device would have to bere-programmed to be able to transfer data with the new printer device byinstalling a printer driver specific to the new printer device. Thus,each application must be explicitly written to use a particular set ofstandardized protocols a priori to communicating with the componentsassociated with the protocols.

[0004] In a system such as Jini™, developed by Sun Microsystems of PaloAlto, Calif. and described in “A collection of Jini™ Technology HelperUtilities and Services Specifications,” Palo Alto, Calif., SunMicrosystems, Inc., pp. 1-214, 2000; and “Jini™ Technology Core PlatformSpecification,” Palo Alto, Calif., Sun Microsystems, Inc., pp. 1-126,2000, all of which are hereby incorporated by reference in theirentirety, which uses domain-specific interfaces, in order for acomponent such as a PDA system to communicate with another componentsuch as a printer, the PDA system must contain a priori knowledge of thesemantics of the printer's programmatic interfaces. In other words, acomponent that knows how to print still might not know how to transferdata between a file system, a scanner device or a network translationservice until it is explicitly programmed to know how to communicatewith the interface for the particular components.

SUMMARY OF THE INVENTION

[0005] A system for enabling components to transfer data between eachother in accordance with the present invention includes a firstcomponent having a universal data transfer interface and a secondcomponent invoking the universal data transfer interface to use a datatransfer session object to transfer data between the first component andat least one of the components.

[0006] A system for enabling components to transfer data between eachother in accordance with the present invention includes a firstcomponent having a first universal data transfer interface, a secondcomponent having a second universal data transfer interface, and a thirdcomponent invoking the first universal data transfer interface and thesecond universal data transfer interface to use a data transfer sessionobject to transfer data between the first component and the secondcomponent.

[0007] A method and a program storage device readable by a machine andtangibly embodying a program of instructions executable by the machinefor enabling components to transfer data between each other inaccordance with the present invention include invoking a universal datatransfer interface to obtain a data transfer session object, and usingthe data transfer session object to transfer data between a firstcomponent and at least one of the components.

[0008] A method and a program storage device readable by a machine andtangibly embodying a program of instructions executable by the machinefor enabling components to transfer data between each other inaccordance with the present invention include invoking a first universaldata transfer interface and a second universal data transfer interface,obtaining a data transfer session object from one of the invoked firstuniversal data transfer interface or the second universal data transferinterface, and using the data transfer session object to transfer databetween a first component and a second component.

[0009] The present invention allows components using the same ordifferent communications protocols and/or data types to transfer databetween each other without having a priori knowledge of anydomain-specific interfaces, protocols or data formats. In addition, theinvention enables components to initiate data transfer sessions betweenother components.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010]FIG. 1 is a diagram of a system for enabling arbitrary componentsto transfer data between each other in accordance with one embodiment;

[0011]FIG. 2 is a block diagram of an exemplary arbitrary componentutilized in the system for enabling arbitrary components to transferdata between each other;

[0012]FIG. 3 is a diagram of a system for enabling one arbitrarycomponent to receive data from another arbitrary component in accordancewith another embodiment;

[0013]FIG. 4 is a flow chart of a process for receiving data fromanother arbitrary component;

[0014]FIG. 5 is a diagram of a system for enabling one arbitrarycomponent to transmit data to another arbitrary component in accordancewith another embodiment;

[0015]FIG. 6 is a flow chart of a process for transmitting data toanother arbitrary component;

[0016]FIG. 7 is a block diagram of a system where one arbitrarycomponent enables two other arbitrary components to transfer databetween each other in accordance with another embodiment; and

[0017]FIG. 8 is a flow chart of a process where an arbitrary componentenables other arbitrary components to transfer data between each other.

DETAILED DESCRIPTION OF THE INVENTION

[0018] A system 10 for enabling arbitrary components to transfer databetween each other in accordance with one embodiment of the presentinvention is shown in FIG. 1. In this particular embodiment, system 10includes computer 20, printer 21, personal digital assistant (“PDA”) 22,server 23 and facsimile machine 24 (“components 20-24”). A method inaccordance with one embodiment includes computer 20 obtaining one of theuniversal data transfer interfaces (i.e., the data source interface orthe data sink interface) associated with one or more of components21-24, and invoking the one or more obtained universal data transferinterfaces to transfer data between components 20-24. The presentinvention allows components 20-24 using the same or differentcommunication protocols and/or data types to transfer data betweenthemselves without having a priori knowledge of any domain-specificinterfaces, protocols or data formats. The present invention alsoenables components 20-24 to initiate data transfer sessions betweenother components 20-24.

[0019] Referring more specifically to FIG. 1, computer 20 is operativelycoupled to each of the components 21-24 in this particular embodiment,although other coupling arrangements or configurations can be used aswell as greater or lesser numbers of components. For example, system 10could comprise one or more of the components 21-24 directly coupled toone or more of the other components 21-24 (e.g., a peer-to-peer system)or system 10 could comprise components 20 and 21, which are coupledtogether.

[0020] A conventional dial-up communication system through privatebranch exchanges (“PBX”) and using public switched telephone lines andline based telephone communication protocols may be used by components20-24 to communicate with each other. Although one type of communicationsystem and protocol is shown, a variety of different types ofcommunication systems and/or protocols may be used. For example,communication systems or network architectures, such as local areanetworks (“LAN”), wide area networks (“WAN”) and cellular or satellitecommunications network systems that utilize signals, such as satellitesignals, radio waves, microwaves and/or infrared signals, can be used.Additionally, a variety of communication protocols for transferringdata, such as xDSL, ISDN, TCP/IP or protocols defined by the RFC and OSIorganizations can also be used. The type of protocol used will dependupon the type of communication system being used by a particularcomponent, the type of component (e.g., a printer device or a scannerdevice) and/or the type of network environment the component isoperating in (e.g., the UNIX operating environment). Components 20-24may use one or more communications protocols. Moreover, the arrows inFIG. 1 depict the flow of communications between components 20-24.

[0021] Referring to FIG. 2, in this embodiment, computer 20 comprises acentral processing unit (“CPU”) 30, memory 32 and I/O unit 34, which arecoupled together by a bus 36, although computer 20 may comprise any typeof device or system that can store, process and execute instructions forperforming one or more methods of the present invention. By way ofexample only, computer 20 may also comprise a scanner, cellulartelephone, display device, video input/output device, audio input/outputdevice, remote control device or an appliance. Computer 20 could alsocomprise any type of device with circuitry that is hard-wired to executeinstructions for performing one or more methods of the presentinvention. Computer 20 executes instructions for an operating systemenvironment it is operating in, such as the UNIX® environment, asdescribed in “Advanced Programming in the UNIX® Environment,” W. RichardStevens, Addison-Wesley Publishing Company, 1974, which is herebyincorporated by reference in its entirety. In this embodiment, computer20 does not use the same communication protocol as any of the othercomponents 21-24, but in other embodiments computer 20 does use the samecommunication protocol as any of the other components 21-24. By way ofexample only, computer 20 may be operating in the UNIX® environmentusing a first type of communication protocol to transfer data, whileprinter 21 may be operating in a Microsoft Windows® environment, butusing a second type of communication protocol.

[0022] CPU 30 may comprise a processor, such as an Intel Pentium IIIprocessor. The CPU 30 executes at least one program of storedinstructions for a method for enabling arbitrary components to transferdata between each other in accordance with the present invention asdescribed and illustrated herein. CPU 30 may also execute instructionsfor other tasks, including network services, such as providing data,memory, file directories, individual files, word processingapplications, accounting applications or engineering applications. As aresult, when one of these applications is executed, the instructions forthe task, such as for creating a spreadsheet, as well as theinstructions for performing one or more of the methods of the presentinvention are carried out by the CPU 30 in computer 20. The instructionsmay be expressed as executable programs written in a number of computerprogramming languages, such as BASIC, Pascal, C, C++, C#, Java, Perl,COBOL, FORTRAN, assembly language, machine code language, or anycomputer code or language that can be understood and performed by theCPU 30.

[0023] Memory 32 may comprise any type of fixed or portable memorydevice accessible by the CPU 30, such as hard-disks, floppy-disks,compact disks (“CD”), digital video disks, magnetic tape, optical disk,ferroelectric memory, read only memory, random access memory,electrically erasable programmable read only memory, flash memory,erasable programmable read only memory, static random access memory,dynamic random access memory, ferromagnetic memory, charge coupleddevices, smart cards, or any other type of computer-readable mediums.Memory 32 stores instructions 38 for a method of enabling arbitrarycomponents to transfer data between each other in accordance with oneembodiment of the present invention for execution by CPU 30, althoughsome or all of these instructions can be stored elsewhere. One or moresets of universal interfaces or data objects may be stored in memory 32so they can be retrieved as needed by the CPU 30 during operation of thepresent invention as will be described in further detail herein.Although in this embodiment the CPU 30 and memory 32 are shown in thesame physical location, they may be located at different physicallocations, such as in server 23 shown in FIG. 1.

[0024] Computer 20 may communicate with components 21-24 using I/O unit34. In this embodiment, I/O unit 34 may comprise a router such as anytype of Ethernet based device having sufficient ports to operativelycouple computer 20 to components 21-24.

[0025] Referring back to FIG. 1, printer 21 comprises a conventionalprinting device capable of rendering graphical representations on aprinting medium, for example. Since devices such as printer 21 are wellknown in the art, the specific elements, their arrangement withinprinter 21 and operation will not be described in detail here.

[0026] PDA 22 comprises a conventional hand held device that may performsuch functions as telephony, facsimile transmissions or networking.Since devices such as PDA 22 are well known in the art, the specificelements, their arrangement within PDA 22 and operation will not bedescribed in detail here.

[0027] Server 23 comprises a conventional computer system having one ormore CPU's, memory, I/O units and one or more storage mediums, which arecoupled together by a bus and used by server 23 to store and processinstructions in accordance with one or more embodiments of the presentinvention as described further herein. Since devices such as server 23are well known in the art, the specific elements, their arrangementwithin server 23 and operation will not be described in detail here.

[0028] Facsimile machine 24 comprises a conventional facsimile devicethat can send and receive pictures or text over a telephone line ornetwork. Since devices such as facsimile machine 24 are well known inthe art, the specific elements, their arrangement within facsimilemachine 24 and operation will not be described in detail here.

[0029] Referring to FIG. 3, computer 20 is coupled to PDA 22 asdescribed above in connection with FIG. 1. PDA 22 has stored in amemory, or otherwise has access to by accessing server 23, for example,which will hereinafter be referred to as being “associated with,” a setof universal interfaces 22 a comprising a data source interface, acontextual interface, a notification interface and a user interface. Theparticular number and/or combination of interfaces may vary and willdepend upon the particular type of device PDA 22 is, and thecapabilities and/or services desired or provided by it. Also, PDA 22,and hence the set of universal interfaces 22 a, may be updated at anytime to add, delete or modify interfaces. Further, computer 20 isprogrammed to access the interfaces associated with PDA 22. Likewise,PDA 22 could access one or more interfaces (not illustrated) associatedwith computer 20.

[0030] Computer 20 may access the set of universal interfaces 22 athrough data object 22 b to effect different types of communications asdescribed herein. Each of the interfaces in the set of universalinterfaces 22 a comprise instructions, sets of operations and/or otherdata that can be understood and performed by computer 20 to enable it tocommunicate and transfer data (i.e., transmitting or receiving data)with PDA 22, exchange contextual information with PDA 22, providecomputer 20 with event notifications for PDA 22, or enable computer 20to receive user interfaces to allow users of computer 20 to accessand/or manipulate PDA 22. In general, each interface in the set ofuniversal interface 22 a is not domain-specific with respect to PDA 22.

[0031] In particular, the data source interface includes severaloperations such as a getSourceDataFlavor( ) operation and abeginTransferSession( ) operation. Further, the data source interfaceincludes instructions and data that can be performed by computer 20 toestablish a data transfer session to enable computer 20 to receive datafrom PDA 22. The getSourceDataFlavor( ) operation includes instructionsand data that may be performed by computer 20 for determining the typesof data PDA 22 can transmit. In this particular embodiment, computer 20performs the getSourceDataFlavor( ) operation that returns a list of oneor more data types supported by PDA 22. Moreover, the data types in thisembodiment are typically MIME data types. For example, after performingthe above-mentioned operations, computer 20 may determine that PDA 22supports data in a “JPEG” format. The beginTransferSession( ) operationincludes instructions and data that may be performed by computer 20 torequest PDA 22 to establish a data transfer session to receive data byreturning a data transfer session object 22 c to computer 20 throughdata object 22 b. Moreover, the beginTransferSession( ) operation may bepassed parameters when invoked such as a context parameter, an initiallease duration parameter and a data flavor parameter. In thisembodiment, computer 20 passes a context parameter to thebeginTransferSession( ) operation when invoking it to inform PDA 22 ofits identity for a variety of reasons, such as for identifying computer20 to PDA 22, identifying a user at computer 20 to PDA 22, identifyingthe location of computer 20 on a network to PDA 22 or for securitypurposes. PDA 22 may decide whether to transmit data to computer 20based upon the identity information provided in the context parameter.Further, data transfer sessions are leased and would thus need to berenewed periodically by computer 20 at intervals of time correspondingto a value specified in the initial lease duration parameter passed tothe beginTransferSession( ) operation to keep the data transfer sessionactive, although in other embodiments the sessions need not be leased.Where sessions are leased, if computer 20 fails to renew the lease PDA22 will stop transmitting data to computer 20 under the assumption thatcomputer 20 has failed to renew the lease because it has either crashedor has otherwise become unreachable. In addition, if PDA 22 supports oneor more types of data, as determined by performing thegetSourceDataFlavor( ) operation, a data flavor parameter may be passedinto the beginTransferSession( ) operation. Computer 20 may provide apreferred data type value to the data flavor parameter for a number ofreasons, such as in the event computer 20 and PDA 22 support multiple,compatible data types where computer 20 specifies, using the parameter,a preferred data type for the data transfer. In this embodiment,computer 20 may determine a preferred data type using a number ofmethods such as enabling users at computer 20 to indicate preferred datatypes, randomly selecting one of the compatible data types betweencomputer 20 and PDA 22 or selecting the data type that will be mostefficient for the particular data being transferred.

[0032] The contextual interface comprises a getcontexto operation thatincludes instructions and data that can be performed by computer 20 forretrieving contextual information from PDA 22. In this embodiment, thecontextual information is stored in a memory at PDA 22 as a multi-valueddata structure that resembles a hash table, although the contextualinformation can be stored in any other format. Also in this embodiment,the contextual information includes information about PDA 22 such aswhat type of device it is, its operating status, identity, location,administrative domain, or any other type of environment data. In anotherembodiment, the contextual information may be stored at another physicallocation such as server 23.

[0033] The notification interface includes a register( ) operation,which may be passed one or more parameters and performed by computer 20to enable it to receive asynchronous notifications about eventsgenerated by PDA 22, although it may receive synchronous notificationsas well. Computer 20 performs the registers operation, passing to it acontext parameter, a component parameter and an initial lease durationparameter. The context parameter provides PDA 22 with the identity ofcomputer 20 for a number of reasons, such as enabling PDA 22 to decidewhether it would desire sending notifications to computer 20 forsecurity purposes or record keeping. The component parameter identifiescomputer 20 as desiring to be notified of events occurring at PDA 22.Further, event registrations are leased and must be renewed periodicallyby computer 20 at intervals of time corresponding to the value specifiedin the initial lease duration parameter to keep the event registrationactive. If computer 20 fails to renew the lease, the notificationinterface includes instructions for relieving PDA 22 of its obligationto provide computer 20 with notifications about generated events sinceit will assume that computer 20 has failed to renew the lease because ithas either crashed or has otherwise become unreachable. Once computer 20has registered itself with PDA 22 by performing the register( )operation, if a condition occurs in PDA 22 that should cause it tonotify computer 20 according to the instructions provided in thenotification interface and associated operations, PDA 22 will send anevent notification object to computer 20. Computer 20 may then generatea user window, as described further herein below, to display the eventinformation to a user. For example, if PDA 22 instead was a printerdevice and computer 20 instead was a word processing application, PDA 22would be able to provide computer 20 with an event notification in thecase where paper in the printer device jammed. Moreover, in thisexample, computer 20 could display the event notification (i.e., paperjam) to the user using a graphical user interface (“GUI”).

[0034] The user interface comprises a getUI( ), getState( ) andsetState( ) operation that includes instructions and data that can beperformed by computer 20 for retrieving or generating a user windowspecific to PDA 22 to provide users of computer 20 with so they canaccess and/or manipulate PDA 22 to take advantage of additionalfunctionality of PDA 22. In this embodiment, the getUI( ) operation canbe passed parameters when invoked by computer 20 to indicate which typeof user window the user would like generated, as described in furtherdetail herein. The getuI( ) operation returns to computer 20, from PDA22, a user window and/or instructions for generating or retrieving auser window, which may be instantiated by computer 20 to display theuser window to users, for example. The getState( ) operation includesinstructions and data for requesting that a state token object bereturned to computer 20 from PDA 22. The state token object may be anopaque object with respect to computer 20, which is particular to PDA 22and further may encapsulate the current state (e.g., device settings orconfiguration) of PDA 22, although the state token object may betransparent with respect to computer 20 in a case where computer 20 isable to understand the state token object of PDA 22. Further, PDA 22 mayuse different types of state token objects depending upon the particulartype of device it is (e.g., a printer device or word processingapplication). Still further, PDA 22 may encode its respective statetoken objects in various ways, such as pointers or URLs pointing toparticular configurations. Alternatively, the state token objects mayinclude a representation of the current state of PDA 22. Additionally,the setstate( ) operation includes instructions and data that may beperformed by computer 20 for generating the user window using theconfiguration data included in the state token object. Computer 20 maypass the state token object as a parameter to the setState( ) operationwhen it is invoked, which can be used by PDA 22 to return instructionsand data that can be performed by computer 20 for retrieving orgenerating the user window having the stored configuration included inthe state token object. The setState( ) operation may also be invoked bycomputer 20 to reset the state of PDA 22 without having to recreate theuser window for the user.

[0035] Each of the above-described interfaces and associated operationstherein, as well as any others that may be subsequently describedherein, comprise mobile code. Mobile code is executable data that can betransmitted to computer 20 where it is executed. For example, Java is animplementation of executable content (i.e., mobile code) that is widelyused on the Internet. Users can download the mobile code from theInternet, for example, and locally run a program written in a trulycommon programming language. In this embodiment, the mobile code isobject oriented mobile code, which is a programming methodology that iswell known in the programming arts, where data types may be definedalong with associated procedures or sets of instructions, the data typesin this context often referred to as classes. Thus, a set of proceduresor instructions may be associated with one or more data types. Moreover,the same name or identifier can be assigned to identify a procedure or aset of instructions that perform corresponding instructions dependingupon the particular data types associated therewith, often referred toas polymorphism. Thus, for exemplary purposes only, a draw procedurecould be performed to draw circles or rectangles depending upon the typeof data provided, or passed, to the procedure when it is invoked.Further in this example, if a circle data type defines a radiuscoordinate, for example, and a draw procedure is invoked and the circledata type is passed to the draw procedure, the draw procedure,inheriting any other data types associated with the draw procedure, canuse the data provided thereto to perform the appropriate procedure orsets of instructions to draw a circle. In this embodiment, when the setof universal interfaces 22 a is provided to computer 20, the procedures,sets of instructions and other data associated with the particularinterface become available to computer 20 to access and perform, as willbe described further herein. Moreover, variables, parameters and datamay be passed or provided to the universal interfaces that will beunderstood and utilized accordingly by computer 20, depending upon theparticular type of communication desired. Still further, the interfacesmay comprise sets of instructions or references to other interfaces,wherein computer 20 could utilize the data or perform the instructionsaccordingly.

[0036] Computer 20 may also directly access each of the interfacesincluded in the set of universal interfaces 22 a without needing toobtain data object 22 b to effect the different types of communicationsdescribed herein. Moreover, each of the interfaces in the set ofuniversal interfaces 22 a would comprise the same instructions, sets ofoperations and/or other data that could be understood and performed bycomputer 20 to enable it to communicate and transfer data with PDA 22 aswell as the other functions described above. Therefore, mobile code maynot be required in this example, although it could be used as necessarysuch as where data is being transferred.

[0037] In this embodiment, data object 22 b is received from PDA 22 andstored in computer 20, although the data object 22 b could be storedelsewhere, such as server 23. The set of universal interfaces 22 a isaccessible to computer 20 through the data object 22 b. Morespecifically, data object 22 b supports the various operations definedby the interfaces associated with PDA 22, which are assumed to be knownand understood by computer 20. The data object 22 b comprisesinstructions (i.e., computer executable code) and/or data that provideparticular implementations of the one or more interfaces associated withthe PDA 22 from which the data object 22 b is associated with. Forexample, data object 22 b as provided by PDA 22 to computer 20 wouldprovide a custom implementation of the data source interface that wouldbe specialized to communicate with PDA 22 using whichever protocolsand/or data formats have been decided upon by the developer of PDA 22.

[0038] In this embodiment, the data transfer session object 22 cincludes a getTransferData( ) operation, a getDataSource( ) operation,an abort( ) operation, a fail( ) operation, a completed( ) operation,the register( ) operation associated with the notification interfacedescribed above, a getLease( ) operation, a getViewer( ) operation, agetEditor operation, a getPrinter( ) operation, as well as any otherinstructions needed to enable computer 20 to receive data from PDA 22,including protocols for video or file transfer, for example, which maydepend upon the type of data being received. Data transfer sessionobject 22 c includes the above-mentioned operations and instructionsthat are particular to PDA 22, but may be performed by computer 20 toreceive data. In an embodiment where computer 20 (i.e., a data sinkcomponent) receives data from PDA 22 (i.e., a data source component),for example, computer 20 invokes the getDataTransfer( ) operation toactually retrieve the data from PDA 22. Further, computer 20 may invokethe getDataSource( ) operation to determine the identity and otherattributes of PDA 22. Computer 20 may also invoke the getDataSource( )operation to determine whether it should modify its behavior during datatransfers or whether it should even allow certain data transfers tooccur.

[0039] In this embodiment, computer 20 does not need to know detailswith respect to how to receive and understand the data sent from the PDA22 through the data transfer session object 22 c. In particular, theinstructions and various operations included within data transfersession object 22 c include information regarding the specificprotocols, mediums and types of data that are particular to PDA 22,which may be executed by computer 20 to be able to receive andunderstand data transferred from PDA 22, even though PDA 22 may utilizedifferent protocols, mediums or types of data. Furthermore, datatransfer session object 22 c includes instructions for enabling computer20 to negotiate with PDA 22 during the transfer of data to select acommunications protocol or medium to use to transfer data between eachother based upon the type of data being transferred. The instructionsmay also enable computer 20 and PDA 22 to negotiate with each other forusing different protocols for the data transfer session based upon thetype of data being transferred. Moreover, the instructions may enablecomputer 20 to modify the format or the content of data beingtransferred through the data transfer session object 22 c to convert thedata as necessary from a first data transfer protocol associated withcomputer 20 to a second data transfer protocol associated with PDA 22.For example, if PDA 22 is transferring streaming video to computer 20,then it may be more efficient for PDA 22 to transfer the data usingcompression or progressive encodings. Computer 20 could perform theinstructions and operations included within data transfer session object22 c so that the data transfer session object 22 c negotiates withcomputer 20 to decide upon the particular protocol to use for the datatransfer session, and in turn provide computer 20, through data transfersession object 22 c, with the operations, instructions and datanecessary to enable computer 20 to retrieve and understand the datatransferred through the data transfer session object 22 c. Further,computer 20 and PDA 22 may negotiate on a preferred physical transportmedium, if one is available. For instance, if a shared FireWire, IR or aBluetooth connection is found to link computer 20 and PDA 22 together itcould be used instead of an Ethernet connection as the physicaltransport medium to transfer the data. The instructions may also includeoperations for scaling down data rates over slow data transmissionlinks, or may include operations for increasing redundancy in the faceof errors during a data transfer session.

[0040] Moreover, data transfer session object 22 c may includeinstructions that may be performed by computer 20 to enable it to viewthe type of data being transferred through data transfer session object22 c. For instance, where computer 20 is not programmed or configured todisplay “JPEG” image files, or streaming video data transferstransmitted from PDA 22, for example, computer 20 may perform theinstructions included in data transfer session object 22 c to view, on adisplay device associated with computer 20, for example, the data beingtransferred. In particular, data transfer session object 22 c mayinclude a getViewer( ) operation that returns a viewer object when theoperation is invoked by computer 20. The viewer object is specific tothe particular type of data that is understood and used by PDA 22.Further, the viewer object may include the same instructions describedabove for providing computer 20 with a user interface except that theinstructions, when performed by computer 20, enable computer 20 to viewthe data being transferred. The viewer object may also includeinstructions for enabling computer 20 to view the particular data typeassociated with PDA 22 and being transferred despite computer 20 notbeing previously programmed to view such types of data. In addition, thegetViewer( ) operation may be passed parameters, as described above withrespect to the user interface, for enabling computer 20 to specify thetype of user window (i.e., graphical or speech) computer 20 would liketo display. In this embodiment, the getViewer( ) operation may be storedin PDA 22 and accessible to computer 20 through data object 22 b.Alternatively or in addition, the getViewer( ) operation may be storedin a central repository, such as in server 23 (FIG. 1). In this example,the server 23 may store one or more getViewer( ) operations, where eachoperation includes instructions for enabling computer 20 to view aparticular type of data. It should be appreciated that the terms “view”or “display” in this embodiment may encompass other forms of output,such as where the instructions in data transfer session object 22 cenable computer 20 to play an audio file in a particular format throughan audio output device such as a speaker. Furthermore, data transfersession object 22 c may include additional operations, such as agetEditor( ) operation and a getPrinter( ) operation, which have thesame instructions as the getViewer( ) operation except the getEditor( )operation and the getPrinter( ) operation include instructions forenabling computer 20 to edit or print, respectively, data beingtransferred, regardless of whether computer 20 has been programmed tounderstand the particular type of data associated with PDA 22. Thus, inthis embodiment computer 20 would not need to understand all of thetypes of data formats it may encounter in a data transfer sessionbecause the instructions to understand such data may be included in datatransfer session object 22 c. It should be noted that computer 20 atleast has the capability of executing the various instructions andoperations included within data transfer session object 22 c.

[0041] In this embodiment, the abort( ) operation includes instructionsthat enable computer 20 to terminate the data transfer session with PDA22. Further, computer 20 may indicate to PDA 22 that a data transfersession has failed or has been completed by performing the fail( )operation or the complete( ) operation, respectively. In the event thata data transfer session between computer 20 and PDA 22 has failed,completed, or aborted, listeners at components 20-24 who expressed aninterest in the status of the data transfer session by registering willbe notified of the event through the register( ) operation. A signalingprotocol enables computer 20 to indicate when computer 20 has completedusing the data transfer session object 21 c in the case where PDA 22cannot automatically determine when computer 20 is finished such aswhere the data transfer session has an indeterminate duration (e.g.,streaming video). The getLease( ) operation enables computer 20 to renewthe lease according to the initial lease duration parameter to ensurethe data transfer session remains active.

[0042] Referring to FIG. 4 at step 40, computer 20 performs a discoveryprocess to determine whether computer 20 and PDA 22 can transfer databetween each other. In this embodiment, computer 20 discovers PDA 22using a variety of discovery systems such as the Bluetooth™ ServiceLocation Protocol (“SLP”) developed by Bluetooth SIG, inc., described in“Specification of the Bluetooth System,” Version 1.1 core, BluetoothConsortium 2001, the Universal Description, Discovery, and IntegrationProtocol (“UDDI”), developed by the Ariba, IBM and Microsoft Corps.,described in “UDDI Technical Whitepaper,” Universal Description,Discovery, and Integration Consortium, pp. 1-12, 2000; “UniversalDescription, Discovery and Integration Data Structure Reference V 1.0,”Ariba, Inc., International Business Machines Corporation and MicrosoftCorporation, pp. 1-31, 2000; “Universal Description, Discovery andIntegration Programmer's API 1.0,” Ariba, Inc. and InternationalBusiness Machines Corporation and Microsoft Corporation, pp. 1-67, 2000;and “Universal Description, Discovery and Integration Technical WhitePaper,” Ariba, Inc., International Business Machines Corporation andMicrosoft Corporation, pp. 112, 2000, the various Jini™ system discoveryprotocols or simple lookup in a name server, for example, all of whichare hereby incorporated by reference in their entirety. Discovered PDA22 returns data object 22 b to computer 20. Computer 20 may introspectthe received data object 22 b to determine which one or more interfacesare associated with PDA 22. Thus, upon computer 20 performing theabove-described discovery and receiving data object 22 b from PDA 22,computer 20 introspects the received data object 22 b to determine whichuniversal interfaces PDA 22 is associated with. Computer 20 determinesthat PDA 22 is at least associated with a data source interface, andthus PDA 22 can provide it with data. Computer 20 invokes the datasource interface associated with PDA 22 and included in data object 22b, which includes instructions that instruct computer 20 to perform thegetSourceDataFlavors( ) operation included in data object 22 b. ThegetSourceDataFlavors( ) operation in turn includes instructions foraccessing PDA 22 to provide computer 20 with the types of data supportedby PDA 22.

[0043] Next, at step 42 computer 20 performs the beginTransferSession( )operation included in the data source interface. In addition, thebeginTransferSession( ) operation when invoked may be passed the contextparameter, the initial lease duration parameter and the data flavorparameter. PDA 22 returns the data transfer session object 22 c tocomputer 20. Computer 20 may determine a preferred data type using themethods described above and provide a preferred data type value toreceive the data in to the data flavor parameter, otherwise computer 20will receive the data in whichever data format it is provided in by PDA22. Computer 20 may receive data from PDA 22 by way of the data transfersession object 22 c.

[0044] Next, at step 44 data transfer session object 22 c includes thegetTransferData( ) operation and the other operations and instructionsdescribed above that may be performed by computer 20 to retrieve datafrom PDA 22. The data is transferred from PDA 22 to computer 20 throughdata transfer session object 21 c at step 46. Still further, computer 20maybe able to view data types that it is not natively programmed tounderstand. When computer 20 performs the beginTransferSession( )operation, PDA 22 may return the instructions, operations or datadirectly to computer 20 to enable it to understand the data beingtransferred from PDA 22.

[0045] Referring to FIG. 5, computer 20 is coupled to facsimile machine24 as described above in connection with FIG. 1. Facsimile machine 24has stored in a memory, or otherwise has access to by accessing server23, for example, a set of universal interfaces 24 a comprising a datasink interface, which will be described in further detail herein.However, facsimile machine 24 may be associated with any number ofinterfaces and in any combination.

[0046] Facsimile machine 24 may access the set of universal interfaces24 a through data object 24 b to effect different types ofcommunications. Each of the interfaces in the set of universalinterfaces 24 a comprise instructions, sets of operations and/or otherdata that can be understood and performed by computer 20 to enable it tocommunicate and transfer data with facsimile machine 24. Except for thedata sink interface, each of the interfaces mentioned above are the sameas those described above in connection with PDA 22, but each interfaceincludes instructions that are specific to the particular device theyare associated with (i.e., facsimile machine 24).

[0047] In particular, the data sink interface includes severaloperations such as a getSinkDataFlavor( ) and a Transfer( ) operation.Further, the data sink interface includes instructions and data that canbe performed by computer 20 for establishing a data transfer session toenable computer 20 to transmit data to facsimile machine 24. Inparticular, the getSinkDataFlavor( ) operation includes instructions anddata that may be performed by computer 20 for determining which types ofdata facsimile machine 24 can support. In this particular embodiment,computer 20 may perform the getSinkDataFlavor( ) operation which returnsa list of one or more data types supported by facsimile machine 24.Moreover, the data types in this embodiment are typically MIME datatypes. The Transfer( ) operation includes instructions and data that maybe performed by computer 20 to request facsimile machine 24 to establisha data transfer session so computer 20 can begin transmitting data tofacsimile machine 24. The Transfer( ) operation may be passed parametersin this embodiment when invoked such as data transfer session object 20c associated with computer 20, a context parameter and a data flavorparameter. In particular, computer 20 passes the data transfer sessionobject 20 c into the Transfer( ) operation to make it available tofacsimile machine 24 so it may perform the instructions therein toactually receive the data from computer 20. In this embodiment, the datatransfer session object 20 c associated with computer 20 includes thesame types of instructions, data and operations as data transfer sessionobject 22 c described above, except that the instructions, data andoperations included therein are particular to computer 20. Computer 20passes a context parameter into the Transfer( ) operation when invokingit to inform facsimile machine 24 of its identity for a variety ofreasons, such as for security purposes. Facsimile machine 24 may decidewhether to allow computer 20 to transmit data to it based upon theidentity information provided in the context parameter. In addition, iffacsimile machine 24 supports one or more types of data, as determinedby performing the getSinkDataFlavor ( ) operation, a data flavorparameter may be passed into the Transfer( ) operation to informfacsimile machine 24 the type of data that will be transmitted bycomputer 20. Moreover, computer 20 may provide a preferred data typevalue to the data flavor parameter for a number of reasons, such as inthe event computer 20 and facsimile machine 24 support multiple,compatible data types where computer 20 specifies, using the parameter,a preferred data type for the data transfer. In this embodiment,computer 20 may determine a preferred data type using a number ofmethods such as enabling users at computer 20 to indicate preferred datatypes, randomly selecting one of the compatible data types betweencomputer 20 and facsimile machine 24 or selecting the data type thatwill be most efficient for the particular data being transferred.Additionally, where computer 20 and facsimile machine 24 support afinite number of compatible data types with respect to each other,computer 20 may select the compatible data type to transmit the data tofacsimile machine 24.

[0048] Referring to FIG. 6, at step 50 computer 20 performs thediscovery process and determines by introspecting data object 24 b, asdescribed above in connection with one or more embodiments, thatcomputer 20 and facsimile machine 24 can transfer data between eachother because facsimile machine 24 is at least associated with a datasink interface. Computer 20 invokes the data sink interface associatedwith facsimile machine 24 and included in data object 24 b, whichincludes instructions that instruct computer 20 to perform thegetSinkDataFlavor( ) operation. The getSinkDataFlavor( ) operation inturn includes instructions for accessing facsimile machine 24 to providecomputer 20 with the types of data supported by facsimile machine 24, asdescribed above.

[0049] Next, at step 52 computer 20 performs the Transfer( ) operationincluded in the data sink interface. In addition, computer 20 passesinto the Transfer( ) operation data object 20 c, the context parameterand the data flavor parameter when invoked as described above.

[0050] Next, at step 54 facsimile machine 24 performs the instructionsincluded within data transfer session object 20 c as provided to itthrough the Transfer( ) operation to receive data from computer 20. Thedata is transferred from computer 20 to facsimile machine 24 by way ofdata transfer session object 20 c at step 56.

[0051] Referring to FIG. 7, computer 20, printer 21 and server 23 arecoupled to each other as described above in connection with FIG. 1. Inthis embodiment, printer 21 is associated with a set of universalinterfaces 21 a comprising a data source interface, a data sinkinterface and a contextual interface. Server 23 is associated with a setof universal interfaces 23 a comprising a data source interface, a datasink interface and a contextual interface. Each of the interfacesmentioned above are the same as those described above in connection withFIGS. 3 and 5, except that each interface in this embodiment includesinstructions that are specific to the particular device they areassociated with (i.e., printer 21 or server 23). Moreover, the datatransfer session object 25 associated with printer 21 includes the sameinstructions, data and operations as data transfer session objects 20 cand 22 c as described above, except that the instructions, data andoperations included therein are particular to printer 21.

[0052] Referring to FIG. 8, at step 60 computer 20 performs thediscovery process and determines by introspecting data objects 21 b and23 b, as described above in connection with one or more embodiments,that printer 21 and server 23 can transfer data between each otherbecause printer 21 is associated with a data source interface and server23 is associated with a data sink interface. Computer 20 invokes thedata source interface associated with printer 21 and performs thegetSourceDataFlavors( ) operation included in data object 21 b to accessprinter 21 to determine the types of data supported by printer 21, asdescribed above.

[0053] Next, at step 62 computer 20 performs the beginTransferSession( )operation included in the data source interface. In addition, thebeginTransferSession( ) operation may be passed the context parameterassociated with computer 20 or server 23. For instance, computer 20 mayinvoke the contextual interface associated with server 23 and accessiblethrough data object 23 b. In this example, computer 20 would receive thecontextual information from server 23 but in turn provide it to printer21 through the beginTransferSession( ) operation. This enables printer21 to decide whether it would like to transfer the data with server 23.Alternatively, computer 20 may provide its own contextual information toprinter 21 for the same reasons as well as the initial lease durationparameter when invoked as described above. Computer 20 invokes the datasink interface associated with server 23 and included in data object 23b, which includes instructions that instruct computer 20 to perform thegetSinkDataFlavor( ) operation. The getSinkDataFlavor( ) operation inturn includes instructions for accessing server 23 to provide computer20 with the types of data supported by server 23. In addition, if server23 supports one or more types of data, as determined by performing thegetSinkDataFlavor( ) operation, a data flavor parameter may be passedinto the Transfer( ) operation to inform server 23 the type of data thatwill be transmitted to it. Moreover, computer 20 may provide a preferreddata type value to the data flavor parameter for a number of reasons,such as in the event printer 21 and server 23 support multiple,compatible data types where computer 20 specifies, using the parameter,a preferred data type for the data transfer between printer 21 andserver 23. Printer 21 returns the data source object 25 to computer 20through data object 21 b.

[0054] Next, at step 64 computer 20 performs the Transfer( ) operationincluded in the data sink interface associated with server 23 andincluded in data object 23 b. The Transfer( ) operation may also bepassed parameters when invoked, including the data source object 25received by computer 20 from printer 21, a context parameter and/or thedata flavor parameter associated with printer 21. Computer 20 providesto server 23 the context parameter associated with computer 20 and/orprinter 21 so that server 23 may decide whether it would like toparticipate in the data transfer for a number of reasons, such as forsecurity purposes. Computer 20 is able to provide server 23 with its owncontextual information by performing its own instructions to obtain itscontextual information and passing the information into the Transfer( )operation via the context parameter. Server 23 may receive data fromprinter 21 by way of the data transfer session object 25 received fromcomputer 20 from printer 21 and transferred to server 23 from computer20 through the Transfer( ) operation.

[0055] Next, at step 66 server 23 performs the getTransferData( )operation included in data transfer session object 25 to retrieve datafrom printer 21. The data is transferred from printer 21 to server 23through data transfer session object 25 at step 68. In this embodiment,one or more of computer 20, printer 21 or server 23 may access andperform the abort( ) operation, fail( ) operation or the complete( )operation described above and included in the data transfer sessionobject 25. Also, one or more of computer 20, printer 21 or server 23 maybe held responsible for renewing the leased data transfer session. Inanother embodiment, one or more of computer 20, printer 21 or server 23may register as a listener with each other by invoking the notificationinterface (not illustrated) associated with computer 20, printer 21 orserver 23 to receive event notifications, as described above. In thisexample, computer 20 may invoke the notification interface associatedwith printer 21 and/or server 22 to register as a listener to monitorthe progress of the data transfer. During the data transfer sessionbetween printer 21 and server 22 the participation of computer 20 is notrequired. Whether or not computer 20 continues to participate in thedata transfer session depends upon several factors, such as whethercomputer 20 would like to receive event notifications associated withthe data transfer sessions and whether computer 20 is responsible forrenewing the leased data transfer session, as described above.

[0056] In another embodiment, any one of computer 20, printer 21 orserver 23 may serve as data sources and data sinks between each otheremploying one or more of the above-described embodiments. For instance,computer 20 may initiate a data transfer where server 23 serves as adata source and thus transmits data to printer 21 via data objecttransfer session 25 following the same steps as described above withrespect to printer 21 transmitting data to server 23.

[0057] While devices such as computer 20, printer 21, PDA 22, server 23and facsimile machine 24 (i.e., components 20-24) have been used asexamples in one or more embodiments described above, a number of othersystems may be used as components 20-24 such as software services,applications or portions thereof including language translationservices, data format converters, e-mail applications, calendarapplications, or a spell checking routine executing within a wordprocessing application. For instance, a word processor could makecurrently selected text available as a data source component so that itcould be sent to PDA 22, which is a data sink component.

[0058] Other modifications of the present invention may occur to thoseskilled in the art subsequent to a review of the present application,and these modifications, including equivalents thereof, are intended tobe included within the scope of the present invention. Further, therecited order of processing elements or sequences, or the use ofnumbers, letters, or other designations therefor, is not intended tolimit the claimed processes to any order except as may be specified inthe claims.

What is claimed is:
 1. A system for enabling components to transfer databetween each other, the system comprising: a first component having auniversal data transfer interface; and a second component invoking theuniversal data transfer interface to use a data transfer session objectto transfer data between the first component and at least one of thecomponents.
 2. The system as set forth in claim 1 wherein the at leastone of the components comprises the second component or a thirdcomponent.
 3. The system as set forth in claim 1 wherein the at leastone of the components sends the data transfer session object to thefirst component to be used by the first component for receiving datatransmitted from the at least one of the components.
 4. The system asset forth in claim 1 wherein the at least one of the components receivesthe data transfer session object from the first component to be used bythe at least one of the components for receiving data transmitted fromthe first component.
 5. The system as set forth in claim 1 wherein theuniversal data transfer interface and the data transfer session objecthave source-specific object-oriented mobile code that can be interpretedand performed by the first component or the at least one of thecomponents to receive data.
 6. The system as set forth in claim 1wherein the data transfer session object comprises instructions forenabling the first component or the at least one of the components tonegotiate with each other to transfer data, for selecting acommunications protocol to use to transfer data between each other basedupon a type of data being transferred or for selecting a transfer mediumto use to transfer data based upon the type of data.
 7. The system asset forth in claim 1 wherein data transfer ceases upon the firstcomponent or the at least one of the components failing to renew a datatransfer lease or indicating that the data transfer has completed orfailed.
 8. A system for enabling components to transfer data betweeneach other, the system comprising: a first component having a firstuniversal data transfer interface; a second component having a seconduniversal data transfer interface; and a third component invoking thefirst universal data transfer interface and the second universal datatransfer interface to use a data transfer session object to transferdata between the first component and the second component.
 9. The systemas set forth in claim 8 wherein the third component sends the datatransfer session object to the first component to be used by the firstcomponent for receiving data transmitted from the second component. 10.The system as set forth in claim 8 wherein the third component sends thedata transfer session object to the second component to be used by thesecond component for receiving data transmitted from the thirdcomponent.
 11. The system as set forth in claim 8 wherein data transferceases upon the first component or the at least one of the componentsfailing to renew a data transfer lease or indicating that the datatransfer has completed or failed.
 12. A method for enabling componentsto transfer data between each other, the method comprising: invoking auniversal data transfer interface to obtain a data transfer sessionobject; and using the data transfer session object to transfer databetween a first component and at least one of the components.
 13. Themethod as set forth in claim 12 wherein the at least one of thecomponents comprises the second component or a third component.
 14. Themethod as set forth in claim 12 further comprising sending the datatransfer session object to the first component to be used by the firstcomponent for receiving data transmitted from the at least one of thecomponents.
 15. The method as set forth in claim 12 further comprisingreceiving the data transfer session object from the first component tobe used by the at least one of the components for receiving datatransmitted from the first component.
 16. The method as set forth inclaim 12 wherein the universal data transfer interface and the datatransfer session object have source-specific object-oriented mobile codethat can be interpreted and performed by the first component or the atleast one of the components to receive data.
 17. The method as set forthin claim 12 wherein the data transfer session object comprisesinstructions for enabling the first component or the at least one of thecomponents to negotiate with each other to transfer data, for selectinga communications protocol to use to transfer data between each otherbased upon a type of data being transferred or for selecting a transfermedium to use to transfer data based upon the type of data.
 18. Themethod as set forth in claim 12 further comprising ceasing data transferupon the first component or the at least one of the components failingto renew a data transfer lease or indicating that the data transfer hascompleted or failed.
 19. A method for enabling components to transferdata between each other, the method comprising: invoking a firstuniversal data transfer interface and a second universal data transferinterface; obtaining a data transfer session object from one of theinvoked first universal data transfer interface or the second universaldata transfer interface; and using the data transfer session object totransfer data between a first component and a second component.
 20. Themethod as set forth in claim 19 further comprising sending the datatransfer session object to the first component to be used by the firstcomponent for receiving data transmitted from the second component. 21.The method as set forth in claim 19 further comprising sending the datatransfer session object to the second component to be used by the secondcomponent for receiving data transmitted from a third component.
 22. Themethod as set forth in claim 19 further comprising ceasing data transferupon the first component or the at least one of the components failingto renew a data transfer lease or indicating that the data transfer hascompleted or failed.
 23. A computer readable medium having storedthereon instructions for enabling components to transfer data betweeneach other, which when executed by one or more processors, causes theprocessors to perform: invoking a universal data transfer interface toobtain a data transfer session object; and using the data transfersession object to transfer data between a first component and at leastone of the components.
 24. The medium as set forth in claim 23 whereinthe at least one of the components comprises the second component or athird component.
 25. The medium as set forth in claim 23 furthercomprising sending the data transfer session object to the firstcomponent to be used by the first component for receiving datatransmitted from the at least one of the components.
 26. The medium asset forth in claim 23 further comprising receiving the data transfersession object from the first component to be used by the at least oneof the components for receiving data transmitted from the firstcomponent.
 27. The medium as set forth in claim 23 wherein the universaldata transfer interface and the data transfer session object havesource-specific object-oriented mobile code that can be interpreted andperformed by the first component or the at least one of the componentsto receive data.
 28. The medium as set forth in claim 23 wherein thedata transfer session object comprises instructions for enabling thefirst component or the at least one of the components to negotiate witheach other to transfer data, for selecting a communications protocol touse to transfer data between each other based upon a type of data beingtransferred or for selecting a transfer medium to use to transfer databased upon the type of data.
 29. The medium as set forth in claim 23further comprising ceasing data transfer upon the first component or theat least one of the components failing to renew a data transfer lease orindicating that the data transfer has completed or failed.
 30. Acomputer readable medium having stored thereon instructions for enablingcomponents to transfer data between each other, which when executed byone or more processors, causes the processors to perform: invoking afirst universal data transfer interface and a second universal datatransfer interface; obtaining a data transfer session object from one ofthe invoked first universal data transfer interface or the seconduniversal data transfer interface; and using the data transfer sessionobject to transfer data between a first component and a secondcomponent.
 31. The medium as set forth in claim 30 further comprisingsending the data transfer session object to the first component to beused by the first component for receiving data transmitted from thesecond component.
 32. The medium as set forth in claim 30 furthercomprising sending the data transfer session object to the secondcomponent to be used by the second component for receiving datatransmitted from a third component.
 33. The medium as set forth in claim30 further comprising ceasing data transfer upon the first component orthe at least one of the components failing to renew a data transferlease or indicating that the data transfer has completed or failed.